Greetings and salutations! Welcome to the Scripter 2.0 demo version.
This document contains information for current Scripter users. If you haven't used Scripter before, read the "About the Demo - Read me first" document.
Installation
You can place the Scripter demo application anywhere you like, except the Desktop.
New Debugging Features
A number of new features revolve around debugging handlers. The next three features presume some working knowledge of debugging in Scripter.
• Call box
You can arbitrarily call any handler (including run, idle, or open handlers, and handlers in a FaceSpan script that you've got open in Scripter) at any time during your debugging sessions (even while stopped a step, if you set it up), by typing a call in the Call box and then initiating the call. This is useful for debugging new or modified handlers [the old way was to type calls to test them, thus requiring you to modify your script just for testing (yuk!) -- not anymore!].
This means you can simulate calls, known as "messages," to your applet's handlers as if they were called from other applications. You can also simulate handler calls being interrupted by new handler calls, by typing new calls in the Call box (or making the same call again) and starting calls while calls are already being handled.
As you can imagine, with all this, things can get a little confusing (just like in real applet calls), so we've added some things to help you sort it all out. For starters, the Log window now includes Call box calls; you can keep track of when a call starts and when it unwinds. If you think this is cool, take a look at this:
• External message handling
You can set things up so that messages directed to Scripter can be directed at your script. This is known as "interapplication messaging," or "listening." Click the "Listen" checkbox to the left of the Options button in the desired script window and it all just happens. Messages received will appear in the Call box and when you initiate the call, they will call the handlers in your script.
You can fetch the messages into the Call box one-at-a-time (Manual), or let things happen automatically (Auto), or shut this off entirely, rejecting inbound messages, by unchecking the "Catch Messages" checkbox. Naturally, the script must be compiled for all this to work properly, otherwise messages will be rejected back to the sender.
You can look at the list of messages waiting, as well as those currently being handled in your script's handlers, and examine any waiting messages.
• Call control
You can abort a handler call while stopped at a step, causing you to return to the point where the handler was called; if called from the Call box, you'll be returned to before the call was initiated. This will allow you to make changes to the handler, or the parameter values on the call, and recompile the script, and then try the call again.
You can cancel a currently handled external message, thereby releasing the sending application from the outstanding message, if you don't want the sender to be hung up waiting.
If a currently handled external message encounters an error, you can return the error back to the sending application; similar to cancelling the message, but directs the error to the sender.
• Call prefs
There are options for controlling whether you want to allow or disallow Call box calls during regular calls or during Call box calls. You can allow auto-stepping to begin upon starting a Call box call, and allow Call box calls to be started automatically upon receipt and just sit back and watch the dance!
New Editing Features
• Object map
After drawing diagrams for nearly two years, we've come up with a diagrammatic representation of the containment hierarchy for scriptable applications. If you double-click on an App Bar icon while holding down the Control key, you'll see a navigable list of an application's top level classes. You can explore the relationship between object classes under your control, and most importantly, the picture of the hierarchy is always accurate, regardless of the complexity of the application being examined.
• Construct generators
You can make your own construction generators (like the Make Try tool in the tools palette). These are known as "Wraps".
• Other new editing tools
In addition to the large assortment of editing tools, Scripter now can "stringify" and "destringify" strings, find backwards, and lots more.
A Word About Breakpoints
Although not mentioned in the manual, breakpoints have been available since the first release. There are some limitations, so because of this, we didn't include it as a documented feature. We've decided to tell you about them, including both their limitations and their power.
The idea behind breakpoints is to stop the debugging process whenever a breakpoint is reached in a script. This can be a powerful aid in debugging; to set a breakpoint, simply click to the left of the command where you want stepping to stop.
Breakpoints can only be set in scripts that have been compiled; if you make a change to a script, you can set breakpoints after recompiling. Further, while all breakpoints in the step area will remain set after each execution or stepping session (or aborted debugging attempt), they are cleared after each recompile. For the most part, this is okay, since you'll probably want to set a breakpoint, examine the problem when you get there, and not want it the next time around. [Note that watchpoints and conditional breakpoints do not clear when you compile a script.]
Please note that breakpoints that you set for commands within handlers will only be noticed by the debugger if you step into the handler that contains them. In other words, the step indicator (arrow) must touch the breakpoint symbol for the breakpoint to be noticed. You, not the debugger, have control from moment to moment over whether or not you will step into a handler, by using the Shift or Caps Lock key. Based on this, you can decide whether you want a breakpoint in a handler to be noticed at any given moment.
This debugging experience is quite different from many such traditional environments. In Scripter, you'll typically step through your script until you encounter a problem, check out the situation with the target applications involved, examine some variables, and experiment around with attempting to fix the bug. Quite often, you'll be successful with a fix, and then go on to the next bug, where you'll repeat the exercise. So the need to frequently recompile a script is eliminated, since you can debug as you go. A debugging session may take a long time, ranging from several minutes to hours, but frequently you can find and solve all (or most) of your problems without having to start over after each one, and when you're done, you're done. Scripter was designed with this sort of debugging scenario in mind, so take advantage of the power it offers.
Thoughts on ScriptBase
[We've integrated ScriptBase into the Scripter environment; the full version comes with these capabilities. The following is designed to stimulate some of your thinking as you use AppleScript and work with Scripter.]
ScriptBase is Main Event's persistent value and object database for AppleScript. It functions as direct storage driven by AppleScript commands in your scripts, "super-globals" as it were. These values and objects are available to any script running on a computer using simple, easy-to-understand commands to store, retrieve, and maintain the data. So a FaceSpan application could set a value, a stay-open applet can grab it and modify it, an AppleScript running in HyperCard might access it, and finally it could be picked up by an AppleScript CGI. Or you could simply set a value from Scripter, and all these other scripts could just refer to it as a common value that's needed everywhere.
Now that Scripter has been released for over a year, and ScriptBase has been out for a couple of years, some of the uses for ScriptBase have become clearer. So far, its main use has been to store commonly accessible values and objects, so that they are available to any script running on your computer, and indeed, that is its primary function. But what that has come to mean has changed, based on the changing nature of the uses for AppleScript.
In the publishing industry, for example, the ability to collect pieces of information of different types can be useful to users. This applies to both information which should be made available to any project a user works on (such as logos and company or department info that doesn't change often), as well as information which needs to be gathered together in one place which a current project is being worked on (such as illustrations or photos stored as PICTs, and records from databases or lists of properties from objects in documents in QuarkXPress).
For those who are solutions-oriented, and need to install scenarios based on a number of AppleScript scripts, you can develop scripts that are easily transportable to many machines. Instead of hard-coding values in each script's properties, and having to run each of them once on each client machine, prompting for user names, file and folder paths, and machine-specific preferences, you can simply make references to values or objects by name in your scripts. Write an initialization script where you prompt for these values and store them as ScriptBase values, as part of your installation. When you get to each individual machine, simply run your initialization script, answering the prompts, the values specific for that machine will be stored in the ScriptBase on that machine, and all your scripts will now magically run on the new machine, without modification.
Also, with a single command in AppleScript, you can store the entire contents of a drawer (akin to a folder) to a single file. The drawer can be loaded into a ScriptBase running on another machine, again with a single command. This means that you can make the installations of your AppleScript-related scenarios much smoother.
The newest use for AppleScript that has emerged in the last six months is for back-end Web server (CGI) applications. Because of its more English-like syntax (HyperTalk TNG), WebMasters who are decidly not programmers can accomplish a range of tasks by writing AppleScript-based CGIs. It becomes useful to store HTML headers (and header fragments) in a central place which can be accessed by any CGI script, and which are independent of any individual script.
We discovered a few months ago, somewhat surprisingly, that you can store scripts and handlers in ScriptBase, and then load them into scripts dynamically and feed them parameters on-the-fly. The effect of this is twofold: Firstly, by writing and perfecting reusable handlers that perform useful functions, you can now maintain significantly smaller scripts, and speed up the time required to develop more complex scenarios. Secondly, you can assemble and maintain libraries of handlers that can easily be shared between scripts, such as different CGIs that are running on your machine. This gives a consistency to all the CGIs that you develop.
There are likely many uses for ScriptBase that we haven't thought of or seen yet.
PRICING AND ORDERING
The suggested price for the Scripter package is US $199. Scripter is available from:
